The pipeline system for Octave and Matlab (PSOM) by Various Authors

The pipeline system for Octave and Matlab (PSOM) by Various Authors

Author:Various Authors
Language: eng
Format: epub
Tags: pipeline, workflow, Octave, Matlab, open-source, parallel computing, high-performance computing, neuroimaging
Published: 2015-05-01T16:00:00+00:00


5.2. Building modules for a pipeline : the “brick” function type

The bricks are a special type of O/M function which take files as inputs and outputs, along with a structure to describe some options. In brief, a brick precisely mimics the structure of a job in a pipeline, except for the files_clean field. The command used to call a brick always follows the same syntax:

[files_in,files_out,opt] = brick_name(files_in,files_out,opt)

where files_in, files_out and opt play the same roles as the fields of a job. The key mechanism of a brick is that there will always be an option called opt.flag_test which allows the programmer to make a test, or dry-run. If that (boolean) option is true, the brick will not do anything but update the default parameters and file names in its three arguments. Using this mechanism, it is possible to use the brick itself to generate an exhaustive list of the brick parameters, and test if a subset of parameters are acceptable to run the brick. In addition, if a change is made to the default parameters of a brick, this change will be apparent to any piece of code that is using a test to set the parameters, without a need to change the code.

When the file names files_in or files_out are structures, a missing field will be interpreted either as a missing input which can be replaced by a default dataset, or an output that does not need to be generated. If the field is present but empty, then a default file name is generated. Note that an option opt.folder_out can generally be used to specify in which folder the default outputs should be generated. Finally, if a field is present and non-empty, the file names specified by the users are used to generate the outputs. These conventions allow complete control over the number of output files generated by the brick, and the flexibility to use default names. The following example is a dry-run with a real brick implemented in the neuroimaging analysis kit17 (NIAK) (Bellec et al., 2011):

files_in = '/database/func_motor_subject1.mnc'; files_out.filtered_data = ''; files_out.var_low = ''; opt.hp = 0.01; opt.folder_out = '/database/filtered_data/'; opt.flag_test = true; >>[files_in,files_out,opt] = … niak_brick _time_filter(files_in,files_out,opt) files_in = /database/func_motor_subject1.mnc files_out = { filtered_data = /database/filtered_data/ /func_motor_subject1_f.mnc var_high = gb_niak_omitted var_low = /database/filtered _data//func_motor_subject1_var_low.mnc beta_high = gb_niak_omitted beta_low = gb_niak_omitted dc_high = gb_niak_omitted dc_low = gb_niak_omitted } opt = { hp = 0.010000 folder_out = /database/filtered_data/ flag_test = 1 flag_mean = 1 flag_verbose = 1 tr = -Inf lp = Inf }

The default output names have been generated in opt. folder_out, and some of the outputs will not be generated (they are associated with the special tag ’gb_niak_ omitted’). A large number of other parameters that were not used in the call have been assigned some default values.



Download



Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.